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1  Introduction 

W e  live  in  an  age  of  distributed  processing.  Desktop  workstations  connected  by 
high-bandwidth  networks  to  one  or  more  central  processors  and  memory  stores 
have  become  ubiquitous  at  universities  and  research-oriented  companies.  Per¬ 
sonal  computers  connected  by  local  networks  are  common  in  smaller  companies 
and  colleges.  Modern  computers  can  have  several,  even  thousands,  of  separate 
processors.  As  software  engineers,  we  want  to  be  able  to  utilise  the  full  power 
of  this  technology — but  at  the  same  time,  we  want  to  avoid  having  to  under¬ 
stand  the  inner  complexities.  We  want  to  be  able  to  develop  programs  that  run 
on  several  processors  simultaneously  and  interdependentiy,  avoiding  destructive 
interactions  yet  allowing  for  all  necessary  and  useful  constructive  interactions. 

Since  the  early  60’s,  researchers  have  attempted  to  provide  this  power  to  us, 
using  such  techniques  as  coroutines,  critical  sections,  and  semaphores.  With  the 
invention  of  guarded  commands  [D\j75],  we  had  the  ability  to  create  programs 
that  acted  nondeterminuticaUf,  yet  were  provaklg  correct.  The  result  of  this 
is  that  we  now  had  a  tool  for  harnassing  the  power  of  parallel  processing  in  a 
manner  that  would  ensure  our  processes  behaved  as  specified. 

So  we  could  now,  using  guarded  commands  and  one  of  several  methods  of 
memory  protection  available  (see  [PS85]),  write  parallel  programs  that  worked. 
But  Hoare  had  the  foresight  to  see  that  this  wouldn’t  be  sufficient  for  pro¬ 
grams  running  on  separate  machines,  because  processes  running  on  one  machine 
wouldn't  have  automatic  access  to  information  on  other  machines.  So  Hoare  de¬ 
vised  a  protocol  for  shuttling  information  between  processes.  That  protocol,  in 
combination  with  Dijkstra's  guarded  commands,  became  C’SP. 

When  Hoare  wrote  his  now  famous  paper  outlining  CSP,  he  had  two  objec¬ 
tives  in  mind:  to  create  a  spare  but  powerful  method  of  devising  and  denoting 
multiprocess  programs,  and  to  allow  for  the  exchange  of  information  between 
separate  machines  in  a  useful  and  correct  manner.  In  this  paper,  we  will  exam¬ 
ine  CSP  as  it  evolved  over  the  past  10  years  and  see  whether  these  objectives 
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have  been  met.  We’ll  also  be  examining  the  effect  CSP  and  the  research  it  has 
spawned  have  had  on  software  engineering. 

2  The  Paper  that  Started  it  All 

In  August  of  1978,  exactly  3  years  after  Dijkstra's  paper  on  guarded  commands 
was  published,  Hoare’s  paper  on  Communicating  Sequential  Processes  appeared 
in  the  Communications  of  the  ACM  |Hoa78j.  The  paper  consisted  mostly  of  a 
BNF  grammar  for  his  proposed  language  and  various  applications  of  it.  It  is 
worth  summarizing  each  of  these  parts. 

2.1  CSP  Grammar 

First,  we  summarize  the  grammar.  A  CSP  program  consists  of  one  or  more  pro¬ 
cesses,  which  are  independently  executed  blocks  of  code.  Each  process  consists 
of  a  label,  a  declaration  list  (possibly  empty),  and  a  command  list.  In  the  CSP 
process  below,  P  ::  is  the  label,  integer  i;  is  the  declaration  list,  and  i  :=  0; 
is  the  command  list: 


P  :: 

integer  i; 

i  :=  0; 


Figure  1:  A  simple  CSP  process 

Labels  are  straightforward:  a  name  followed  by  a  double  colon  (::).  A  name 
can  be  subscripted,  if  one  wishes  to  define  several  similar  processes,  like  P(l) 
instead  of  P. 

Declarations  are  much  like  Pascal  declarations,  the  only  major  difference 
being  with  structured  variables.  A  structured  variable  consists  of  an  optional 
label  and  a  list  of  variables.  The  label,  if  given,  strongly  types  the  variable,  so 
that 


T(x,y)  :=  (a,b) 


is  not  allowed,  even  if  x  and  a,  and  y  and  b,  have  the  same  types.  A  structure 
consisting  of  a  label  and  an  empty  variable  list  is  called  a  signal,  and  is  only 
used  in  message  passing. 

Commands  are  the  equivalent  of  statements  in  con  ventional  languages.  There 

are  6  basic  command  types:  assignment,  parallel,  input,  output,  alternative,  and  .  _ 

repetitive.  ‘  Accession  For 
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Parallel  commands  consist  of  a  list  of  processes,  separated  by  double  bars  (II), 
and  surrounded  by  brackets.  This  creates  tbe  set  of  independently  executing 
processes  that  make  up  a  CSP  program.  A  typical  CSP  program  is  just  one 
parallel  command. 

Input  and  output  commands  are  the  protocol  Iloare  devised  to  allow  processes 
to  send  information  to  each  other.  The  process  sending  the  information  issues 
an  output  command  of  the  form: 

process  !  value 

where  protest  is  the  name  of  a  CSP  process  and  value  is  the  value  we're  sending. 
The  process  receiving  the  information  issues  an  input  command  of  the  form: 

process  ?  variable 

where  variable  is  the  location  the  value  is  stored  in.  Note  that  this  includes 
structured  variables. 

In  CSP,  the  corresponding  input  and  output  commands  are  executed  to¬ 
gether.  Which  means  that  if  process  A  issues  an  output  command  to  process  B, 
it  will  not  be  executed  until  process  B  issues  the  corresponding  input  command 
from  process  A.  Likewise,  if  B  issued  the  input  command  first,  it  would  have  to 
wait  for  the  corresponding  output  command  from  process  A.  This  is  the  protocol 
Hoare  devised  to  allow  for  correct  passing  of  information  between  distributed 
processes.  There  are  several  ramifications  of  using  this  protocol,  which  will  be 
discussed  later. 

Alternative  and  repetitive  commands  are  the  guarded  commands  we  referred  to 
earlier.  They  function  exactly  as  discussed  in  Dykstra's  paper,  although  Hoare 
uses  a  slightly  different  notation:  Where  Dijkstra  used  if. . .  ft  to  demarcate 
an  alternative  commaud,  Iloare  uses  brackets  ({...]),  and  where  Dykstra  uses 
do.  ..oil  to  demarcate  a  repetitive  command,  Hoare  uses  brackets  prepended 
by  an  asterisk  (•[. . .  J). 

2.2  CSP  Examples 

As  one  of  Hoare's  primary  goals  in  writing  this  paper  was  to  create  a  simple  yet 
powerful  method  for  designing  concurrent  programs,  he  gave  several  examples 
used  by  other  researchers  in  showing  the  power  of  their  method.  For  instance, 
in  his  paper  on  coroutines,  Conway  gave  the  example  of  reading  in  a  sequence  of 
cards  and  sending  them  to  a  line  printer,  substituting  carets  (*)  in  the  output 
for  double  asterisks  (**)  in  the  input.  Hoare  used  a  straightforward  parallel 
command.  He  also  gave  a  solution  to  the  dining  philosophers  problem  originally 
proposed  by  Dijkstra.  In  this  way,  he  showed  that  his  method  could  well  be 
used  in  situations  where  other  methods  of  safeguarding  memory  were  shown  to 
be  effective. 
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In  addition  to  these,  Hoare  gave  sample  programs  that  showed  that  simple 
processes  connected  by  message  passing  could  work  like  ordinary  subroutines, 
recursive  subroutines  (although  limited  to  a  predefined  level  of  recursion),  and 
as  parallel  abstract  data  types  (which  means  functions  can  operate  on  variables 
of  the  type  concurrently).  These  suggest  that  the  rather  restrictive  protocol 
Hoare  devised  was  powerful  enough  to  perform  everything  we  would  require  of 
a  concurrent  system. 


2.3  Implications  of  the  Article 

It  is  clear  that  Hoare  was  attempting  to  create  a  system  that  would  do  for  con¬ 
current  programs  what  structured  programming  and  Hoare’s  Axioms  [Hoa69] 
did  for  single-stream  processing:  provide  a  single  structurally  sound  and  logi¬ 
cally  complete  system  for  generating  code  to  meet  desired  output  specifications. 
However,  we  must  remember  that  unlike  other  proposed  methods,  no  actual 
CSP  system  existed.  Hoare’s  proposal  was  only  a  draft,  a  gedankenexperitnent. 
No  one  knew  for  sure  whether  such  a  system  could  be  built  as  proposed.  Fur¬ 
ther,  there  was  no  proof  that  even  the  abstract  method  worked  as  expected.  So 
even  if  such  a  system  were  built,  we  could  not  be  sure  it  did  what  we  expected 
it  would. 

The  paper  then,  in  its  attempt  to  provide  a  simple  and  elegant  method 
for  multiprogramming  as  well  as  multiprocessing,  left  two  important  questions 
unanswered:  Can  we  implement  it?  and  Does  it  do  what  we  think  it  does? 
These  are  the  subjects  of  the  next  two  sections  respectively. 

3  Can  We  Implement  CSP? 

It  is  perhaps  to  be  expected  that  a  language  designed  on  paper  would  undergo 
changes  before  reaching  its  final  implemented  state.  Such  is  indeed  the  case 
with  C'SP:  there  are  several  implemented  languages  that  are  based  on  CSP,  yet 
diverge  from  the  original  draft.  For  instance,  it  should  be  expected  that  no 
one  implemented  structured  variables  as  Hoare  devised  them — he  himself  failed 
to  specify  how  one  declares  such  variables,  they  are  syntactic  sugar  and  not 
actually  necessary,  but  most  importantly,  it  is  unwise  to  force  a  process  on  an 
unknown  machine  to  provide  a  correct  abstract  type  name.  We  can  dismiss  this 
feature  as  nonessential  to  the  inherent  structure  of  C’SP. 

It  would,  however,  be  fair  to  say  that  all  present  implementations  of  CSP 
differ  from  the  original  version  in  one  manner  that  is  fundamentally  different 
from  the  original  version.  In  the  original  paper,  Hoare  decided  that  input  and 
output  commands  would  be  process  oriented.  Input  commands  name  the  process 
they  receive  data  from,  and  output  commands  name  the  process  they  send  data 
to.  He  foresaw  the  possibility  of  making  rommuiiication  port  oriented ,  but 
saw  it  as  “semantically  equivalent  to  the  present  proposal,  provided  that  each 
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port  is  connected  to  exactly  one  other  port  in  another  process”  ([Hoa78],  page 
675).  But  Silberschats  showed  that  we  could  look  at  ports  front  a  broader 
perspective  [Sil81|.  To  hint,  a  port  was  a  location  where  any  process  could 
“send”  or  “receive”  messages.  This  is  more  practical  to  implement  than  process 
oriented  messaging,  because  specifying  the  process  instead  of  a  port  forces  the 
compiler  to  generate  the  necessary  ports.  Thus,  all  three  CSP  implementations 
mentioned  in  (Iiul86|  (and  almost  certainly  every  other  implementation)  use 
ports  to  send  and  receive  messages.  As  we  shall  see  in  the  next  section,  we 
cannot  dismiss  this  difference  so  easily. 

I  mentioned  that  there  have  been  several  implementations  of  CSP.  Instead 
of  discussing  all  implementations,  I  will  choose  the  one  I  am  most  familiar 
with,  namely  occam.  (t  is  probably  fair  to  say  that  oerant  is  the  most  robust 
implementation,  any  feature  we  see  in  other  implementations  we  will  also  see  in 
occam.  My  information  comes  from  the  programming  manual  [Lim84]. 

In  CSP,  a  program  was  essentially  a  parallel  command,  which  contained 
the  individual  processes.  Occam  does  allow  one  to  create  named  processes,  but 
since  communication  is  port  oriented,  rather  than  process  oriented,  one  need  not 
name  the  processes  explicitly.  There  is  a  parallel  command1  in  occam,  like  CSP, 
but  process  scope  is  determined  by  indentation  instead  of  name.  For  example, 
the  occam  command 

PAR 
VAR  yl: 
yl  :=  1 
VAR  y2: 
y2  :=  0 

creates  2  processes,  one  sets  variable  yt  to  1,  the  other  sets  y2  to  0.  Note  that 
yl  and  y2  are  local  variables,  and  cannot  be  accessed  by  the  other  process — as 
in  CSP.  Note  that  although  the  following  occam  command  appeart  legal,  it  tries 
to  share  a  common  variable  y  between  two  processes,  which  is  not  allowed. 

VAR  y. 

PAR 
y  1 
y  :=  0 

A  major  difference  between  occam  and  CSP  is  that  occam  isn’t  strongly  typed, 
or  even  weakly  typed.  Types  of  variables  are  determined  by  the  compiler,  and 
not  declared  by  the  programmer.  Clearly  then,  one  can’t  have  typed  signals, 
although  occam  has  a  generic  signal  called  ANY. 

Occam  has  all  6  commands  specified  in  C'SP*,  although  input  and  output 
commands  specify  ports  (called  channel .»  in  occam)  instead  of  processes.  Alter- 

1  Actually,  what  we  call  commands  in  CSP  are  callrd  processes  in  occam.  For  the  sake  of 
clarity,  I  will  call  them  commands. 

’Actually  7,  as  sequencing  mutt  be  explicitly  specified  in  occam  with  the  SEQ  command. 
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native  commands  arc  done  with  the  ALT  command.  Repetitive  commands  are 
trickier:  one  must  enclose  an  ALT  command  in  a  WHILE  command.  WHILE 
is  a  deterministic  conditional  looping  command  (as  in  conventional  program¬ 
ming  languages).  There  is  also  a  deterministic  branching  command,  the  IF 
command.  Subscripting  as  used  in  the  original  paper  is  fully  supported  via 
replicators,  which  allow  one  to  subscript  processes,  channels,  and  commands. 

It  would  seem  that  Occam  has  not  only  met  the  CSP  description  (save  for 
structured  variables,  which  we've  already  dismissed),  it  has  gone  beyond  it,  as 
we  can  use  both  deterministic  and  noudeterministic  commands,  interleaved  in 
any  manner  we  like.  We  also  have  greater  flexibility  in  communicating  through 
the  use  of  user-defined  channels.  So  why  would  we  concern  ourselves  with  trying 
to  implement  a  less  powerful  language?  We'll  see  why  in  the  next  section. 

4  Does  CSP  Do  What  We  Think  It  Does? 

When  Dykslra  originally  devised  structured  programming,  there  were  several 
doubts  raised.  But  perhaps  the  biggest  doubt  raised  was  whether  one  could  do 
everything  under  structured  programming  that  one  could  do  previously.  After 
all,  he  was  reducing  ihe  set  of  programs  one  could  write  by  a  sizeable  amount. 
Maybe  some  programs  wouldn’t  map  into  the  reduced  set.  Fortunately,  Bohm 
and  Jacopini  were  able  to  prove  that  any  program  we  could  write  previously 
could  be  written  under  structured  programming  with  no  loss  of  functionality 
( BJ  66] . 

Hoare’s  paper  on  CSP  has  the  same  effect  regarding  multiprocess  programs: 
he  reduced  the  set  of  possible  concurrent  programs  to  ones  using  guarded  com¬ 
mands  and  a  message-oriented  process- to- process  protocol,  with  no  buffering. 
How  do  we  know  that  every  program  we  would  ever  want  to  write  could  be  done 
using  C'SP? 

Tha«,'s  a  good  question.  But  there's  an  even  better  one:  how  do  1  know 
that  this  CSP  program  l  wrote  will  do  what  I  think  it  will?  You  see,  there 
are  problems  that  can  occur  in  mnltiprocess  programs  that  have  no  correlate 
iu  single-stream  programs  like  deadlock  mid  starvation.  These  are  problems 
that  cannot  be  abstracted  away  by  a  program  canonization,  because  there  are 
programs  that  we  want  to  write  that  have  the  possibility  of  deadlocking  or 
starving  one  of  their  members.  Resource  allocation  programs  for  an  operating 
system  are  but  one  example.  So  theoretical  analysis  of  CSP  has  concentrated 
on  this  aspect. 

For  instance,  Levin  and  Cries  wrote  a  paper  in  1981  which  gave  a  proof  tech¬ 
nique  for  CSP  programs,  although  they  altered  the  definition  slightly  [LC81], 
The  proof  is  based  on  Hoare’s  axiomatic  method  for  single-stream  programs 
[Hoa69),  but  extended  with  a  proof  that  the  program  is  free  from  deadlock.  Apt, 
Frances,  and  de  Roever  did  a  similar  proof  (AFdRSO)-  Each  ptogram  must  be 
proven  individually,  and  as  with  Hoare's  Axioms,  it  is  not  yet  feasible  to  devise 
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an  automatic  theorem  prover.  But  it  is  even  worse  for  multiprocess  programs, 
for  the  reasons  given  above.  If  a  process  is  added  to  a  program  we’ve  already 
proven  correct,  we  may  have  to  start  the  proof  ail  over:  since  the  addition  of  a 
new  process  can  create  deadlocks  where  none  existed  before. 

Hoare  himself  later  added  substantially  to  the  theory  ofCSP  by  publishing  a 
book  jHoa85).  At  this  point,  Hoare  had  the  same  benefit  of  hindsight  that  we  do. 
Every  piece  of  research  I  have  mentioned  took  place  before  he  wrote  the  book. 
He  made  two  major  changes  to  his  theory.  One  was  the  change  front  process- 
oriented  to  port-oriented  communication  we  discussed  earlier,  although  his  ports 
are  unidirectional  one-input-one-output  channels.  The  other  change  was  from  an 
assumption  of  process  termination  to  indefinite  execution  in  parallel  commands. 
At  the  time,  he  wanted  to  be  able  to  use  postconditions  to  prove  correctness 
of  the  code,  as  is  done  with  Hoare's  Axioms  in  conventional  programs.  Later, 
he  was  able  to  find  a  more  satisfactory  way  of  proving  correctness,  thus  he 
abandoned  this  rule. 

The  book  is  not  a  proof  of  C'SP,  it  is  an  axiomatic  system  based  on  the  origi¬ 
nal  BNF  grammar.  Some  things  were  changed,  for  instance  guarded  commands 
were  now  represented  by  a  choice  operator  and  the  guard  was  eliminated.  The 
guard,  of  course,  is  necessary  in  the  actual  program  to  allow  the  programmer  to 
determine  when  a  certain  action  will  happen.  But  if  we’re  only  trying  to  prove 
the  correctness  of  guarded  commands,  we  can  assume  a  generic  guard  with¬ 
out  loss  of  generality.  A  lot  has  been  added:  for  instance,  notations  for  traces 
of  a  program  or  process,  for  various  types  of  interactions  between  processes, 
and  for  general  nondeterminism.  But  now,  instead  of  being  a  set  of  executable 
statements  that  produce  a  desired  result,  a  CSP  program  is  a  set  of  sequen¬ 
tial  streams  of  abstract  events.  And  it  is  not  entirely  clear  how  one  converts  a 
CSP  program  to  a  set  of  sequences  of  abstract  events.  This  is  a  problem  with 
axiomatic  systems  in  general:  making  sure  that  the  universe  the  system  works 
under  maps  to  the  universe  of  interest. 

5  Conclusion 

CSP,  when  originally  designed,  was  to  serve  two  purposes  —one  practical  and  one 
prophetic.  The  practical  idea  was  to  create  an  efficient  paradigm  for  working  on 
multiprocess  programs.  Hoare’s  approach  had  two  main  focal  points:  guarded 
commands  and  message-based  interprocess  communication.  Both  of  these  have 
been  incorporated  in  several  languages,  including  one  that  is  used  for  practical 
programming  (namely  Occam).  But  in  a  practical  sense,  we  can’t  really  say  that 
CSP  is  a  standard.  The  language  Mesa,  for  instance,  is  based  on  monitors ,  which 
have  shared  memory.  Theoretically,  however,  CSP  is  a  standard.  Research  on 
multiprocess  systems,  particularly  distributed  multiprocess  systems,  often  use 
CSP  as  a  model.  For  instance,  Jalote  and  Campbell  used  CSP  to  research 
fault-tolerance  in  interactive  multiprocess  programs  [JC86],  This  is  perhaps 
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to  be  expected,  as  C’SP  was  the  first  proof  system  to  incorporate  distributed 
processes* . 

Which  brings  us  to  the  prophetic  part.  In  1978,  when  Hoare  originally 
devised  C'SP,  there  were  no  distributed  programs.  One  could  of  course  send 
messages  between  machines  using  some  sort  of  mail  facility,  but  each  machine 
ran  a  separate  mailing  program.  It  hadn't  occurred  to  the  general  computing 
populace  to  partition  a  program  and  run  it  on  separate  computers —  after  all, 
intracor.iputer  links  were  faster  and  more  reliable  than  intercomputer  links, 
and  memory  could  be  shared  between  the  processes.  But  since  then,  we  have 
found  uses  for  distributed  programming.  For  instance,  when  one  works  with  an 
interactive  editor  on  a  personal  workstation  attached  by  network  to  a  central 
computer,  the  workstation  will  do  much  of  the  editing  operations  itself,  and  send 
updates  or  commands  it  can't  perform  to  the  central  computer.  While  Hoare 
foresaw  the  possible  uses  of  distributed  processing,  he  could  not  have  predicted 
the  amount  of  research  that  would  be  done  ovet  the  next  10  years.  C'SP  has 
shown  itself  to  be  a  powerful,  flexible,  and  tractable  paradigm;  and  we  are  likely 
to  see  it  used  for  many  years  to  come. 
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3Owicki  and  Cries  developed  a  proof  for  multiprocess  programs  in  1976.  but  they  used  a 
centralised  model. 
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